chore(deps): bump OpenZeppelin 5.6.1 → 5.7.0 — only the wrapped vault's bytecode moves - #300
Open
thedavidmeister wants to merge 3 commits into
Open
chore(deps): bump OpenZeppelin 5.6.1 → 5.7.0 — only the wrapped vault's bytecode moves#300thedavidmeister wants to merge 3 commits into
thedavidmeister wants to merge 3 commits into
Conversation
The only production bytecode this moves is StoxWrappedTokenVault: 5.7.0's ERC4626Upgradeable swaps its private _tryGetAssetDecimals for the shared SafeERC20.tryGetDecimals helper. The candidate pointers regenerate to a fixpoint, cascading through everything that embeds the vault's Zoltu address: its beacon, the beacon-set deployer, the unified deployer and the orchestrator pair. Frozen release-tag snapshots are untouched; nothing deployed changes until a release is cut. Everything else compiles byte-identical under 5.7.0 — in particular the governance timelock: testTimelockPinsMatchCompiledDependency passes unchanged against the 5.7.0 dependency, proving the frozen TIMELOCK_CREATION_CODE / TIMELOCK_RUNTIME_CODEHASH pins (and therefore the three live deployments) are exactly reproduced by the new version. rain-vats 0.1.6 still imports @openzeppelin-contracts-5.6.1/ prefixes internally; two remappings.txt bridge lines point those at the 5.7.0 install so exactly one OZ copy compiles (same class of bridge as the existing @openzeppelin/contracts/ line; re-apply if soldeer regenerates the file) until rain-vats republishes against 5.7.0. Bump-protocol suites all green: LibERC20Storage + LibERC1155Storage (ERC-7201 layout pins), LibStockSplit, LibRebase sequential precision, LibTotalSupply fuzz, LibTimelockInvariants, testCandidateSelfConsistent. StoxReceiptVault runtime 24,058 bytes (518 under EIP-170). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (7)
📒 Files selected for processing (84)
Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe project now targets OpenZeppelin 5.7.0. Configuration, remappings, production imports, deployment scripts, tests, upgrade notes, and deploy-table documentation were updated. ChangesOpenZeppelin dependency upgrade
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This dependency update is merge-ready after normal checks and review; no actionable merge-blocking risk remains. Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
# Conflicts: # src/lib/LibBeaconInvariants.sol
`forge fmt` had never been run over the regenerated
`src/generated/LibProdDeployCurrent.sol` and
`src/generated/LibProdDeployV4.sol`, which reddened both `git-clean`
(regenerates pointers, runs `forge fmt`, asserts an empty `git diff`) and
`rainix-sol / static` (`forge fmt --check`). Single cause, both checks.
Also sweeps the `@openzeppelin-contracts{,-upgradeable}-5.6.1/` import
prefixes in the governance-timelock and fireblocks-revoke scripts/tests
that landed on main after this branch was cut. These already resolved to
the 5.7.0 install via the remappings.txt bridge, so the sweep is a
compiler no-op; it restores the branch's grep-zero-on-old-prefixes claim.
CLAUDE.md: point the dependency list and bump runbook at 5.7.0, and
document the two version-bridge lines in remappings.txt. The bridge note
records what was observed locally -- soldeer install PRESERVES the
hand-added lines; it does not drop them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
|
🤖 ai:producer WHAT IS FIXED (verified)
THE DESIGN QUESTION: which Solidity toolchain is canonical?
The pipeline own tooling already refuses this: I formatted with git-clean toolchain. git-clean went green; static did not. Whether static residual failure is a fmt disagreement between the two forge builds, or an unrelated slither finding, I DID NOT VERIFY - see below. Either way the two-toolchain split is a real defect that makes "format so both checks pass" unanswerable, and choosing between (a) bumping flake.lock to rainlanguage/rainix main or (b) pinning git-clean.yaml to flake.lock rainix rev is a repo-owner call, not mine. WHY I DID NOT ESTABLISH THE STATIC CAUSE (tooling gaps, not choices)
Nothing about the static failure is asserted here beyond the observed fact that it is FAILURE at ac6d5b6 while test, legal, build-artifact and git-clean pass. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Bumps
@openzeppelin-contractsand@openzeppelin-contracts-upgradeablesoldeer deps 5.6.1 → 5.7.0, sweeps the versioned import prefixes across src/test/script, regenerates the candidate pointers to a fixpoint, and records the result in the CHANGELOG.The byte-level answer this PR exists to give
testTimelockPinsMatchCompiledDependencypasses unchanged against the 5.7.0 dependency — the frozenTIMELOCK_CREATION_CODE/TIMELOCK_RUNTIME_CODEHASHpins (and therefore the three live deployments) are reproduced exactly. Independently cross-checked by compiling both tags standalone under the repo's exact profile: identical 8,149-byte creation code, identical runtime keccak0xb623…6993.StoxWrappedTokenVault. 5.7.0'sERC4626Upgradeableswaps its private_tryGetAssetDecimalsfor the sharedSafeERC20.tryGetDecimalshelper. The candidate pointer regeneration cascades through everything embedding the vault's Zoltu address: its beacon, the beacon-set deployer, the unified deployer, and the orchestrator pair. Frozen release-tag snapshots are untouched — nothing deployed changes until a release is cut, at which point this is a new-tag event per the versioning rules.Reviewer decision
rain-vats 0.1.6 still imports
@openzeppelin-contracts-5.6.1/prefixes internally, so tworemappings.txtlines bridge those onto the 5.7.0 install (same class of bridge as the existing@openzeppelin/contracts/line, documented in the CHANGELOG; soldeer regenerating the file would need them re-applied). The alternative is waiting for rain-vats to republish against 5.7.0 and bumping in lockstep — this PR takes the bridge; call it out if you'd rather wait.QA
testCandidateSelfConsistent— fails on base source combined with this branch's regenerated pointers, and was observed failing live on this branch before the pointer fixpoint (candidate constants vs 5.7.0 compile mismatch);testTimelockPinsMatchCompiledDependencydeliberately does NOT discriminate — its passing under 5.7.0 IS the byte-identity claim.testCandidateSelfConsistent(observed directly: the pre-fixpoint tree, where the beacon pointer still carried the 5.6.1-era embedded vault address, failed exactly there with the mismatched bytecode in the assertion output). Dep-version line itself: reverting foundry.toml to 5.6.1 alone → build breaks on the swept import prefixes (compile-time kill).[profile.default](solc 0.8.25, optimizer 2000, cancun, no metadata) — pointer expectations come from the compiler over the dependency, never hand-written; for the timelock additionally the three live on-chain deployments the frozen pins describe.🤖 Generated with Claude Code
Summary by CodeRabbit
Updates
Documentation